Messages view does not indicate that it is waiting for a response from ServiceControl#3047
Conversation
…filtered after the first load
|
Tamara and I are going to push a commit for a new direction. AuditList knows if a query is running. It should disable all of the form fields that can trigger a new query. We will abandon the 1 second refresh because now there is a loading spinner. A future feature can add cancellation which is probably needed. |
Co-authored-by: Tamara Rivera <tamita.rivera@gmail.com>
Prettier hates me Co-authored-by: Tamara Rivera <tamita.rivera@gmail.com>
Co-authored-by: Tamara Rivera <tamita.rivera@gmail.com>
|
Sorry, I ended up reviewing this PR, I couldn't resist 🙂 This PR is a massive improvement, and I am not suggesting changing it at all, but I thought I'd share this blog about using skeleton shimmers vs spinners. I have been reading more about this topic and thought it may be beneficial to consider in a future PR. |
Co-authored-by: John Simons <john.simons@particular.net>
# Conflicts: # src/Frontend/src/components/audit/AuditList.vue
There was a problem hiding this comment.
FilterInput can still have a pending debounced model update when the controls become disabled. If that debounce fires during the in-flight request, AuditList updates the route/filter state and calls refreshNow, but useFetchWithAutoRefresh returns early while already refreshing. That can leave the input/URL ahead of the displayed results. Not necessarily a blocker for this PR, but flushing the debounce on disable or queuing one follow-up refresh would close the loop.
This is an edge case that is a race-condition likely only with auto-updates. So this is optional IMO.
Better would be for us to not automatically submit queries.
| const debounceUpdateModel = useDebounceFn((value: string) => { | ||
| model.value = value; | ||
| }, 600); | ||
|
|
There was a problem hiding this comment.
| watch( | |
| () => props.disabled, | |
| (disabled) => { | |
| if (disabled) { | |
| debounceUpdateModel.flush(); | |
| } | |
| } | |
| ); | |
| @@ -1,2 +1,2 @@ | |||
| <script setup lang="ts"> | |||
| import { computed, useTemplateRef } from "vue"; | |||
There was a problem hiding this comment.
| import { computed, useTemplateRef, watch } from "vue"; |
ngallegos
changed the title
4 participants
Symptoms
Who's affected
All users of ServicePulse, but more so those where HTTP requests to ServiceControl from the Messages view take longer to resolve.
Root cause
The UI only had a loading indicator showing on the first load, not on subsequent requests from auto-refresh, searching, or filtering.
Confirmed workarounds
None
Additional Information
When HTTP calls to ServiceControl take longer than expected, the audit messages view does not make it clear that the user is waiting for something to finish. This introduces some UI improvements to help with that:
Reviewer Checklist